Internet Surfer 2.0

home *** CD-ROM | disk | FTP | other *** search

/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.382 < prev next >

Wrap

Text File | 1996-02-12 | 27.6 KB | 705 lines

Frequently Asked Questions (FAQS);faqs.382 ----------------------------------------------------------------------------- Subject: 108) The OpenWindows server hangs when I popup a menu with Button 3. [Last modified: August 92] Answer: This is an OpenWindows problem, but if you have Motif source you can fix your own applications. From Steve Sistare of Thinking Machines Corp.: "Change the 2 calls to XtGrabButton in RowColumn.c such that ButtonReleaseMask | ButtonPressMask is passed for the event mask. Currently, only ButtonReleaseMask is passed. Also, change the owner_event argument to FALSE. " This has not been fixed in Motif as at 1.1.5. ----------------------------------------------------------------------------- Subject: 109) Has anyone made shared libraries on an IBM RS/6000? Answer: From Sakari Jalovaara: There is a problem: Xm redefines VendorShell and the AIX linker put _both_ Xm's and Xt's VendorShell into programs. When an AIX shared library is created as many references inside the library are resolved as possible. If the symbol vendorShellClassRec is defined in libXt and referenced, say, from a function XtFoo() also in libXt, the "ld" run that creates the shared library resolves the reference: XtFoo() -> vendorShellClassRec Then I create the Motif library that has its own vendorShellClassRec and an XmBar() function that uses it; libXm will also contain a resolved reference to vendorShellClassRec: XmBar() -> vendorShellClassRec Finally, I link a program that uses both XtFoo() and XmBar() and the program will end up with _two_ independent "vendorShellClassRec"s: XtFoo() -> vendorShellClassRec [Xt version] XmBar() -> vendorShellClassRec [Xm version] Instant schizo zaphod mode. In reality, vendorShellClassRec is not referenced from functions but from other widget class records. I can't just pull Vendor.o out from the shared Xt (Vendor.o appears to define the only external symbols redefined by libXm) because AIX shared libraries apparently can't contain unresolved external references. If I take out Vendor.o I have to take out every other file that uses symbols defined there - and then files that need those files, etc. I tried it and ended up with three or four object files in libXt and the res non-sharable. I kludged around this by putting all of libXt (minus Vendor.o) into the shared libXm. It isn't a pretty solution but it works - and beats having a statically linked two-megabyte "periodic" demo... ----------------------------------------------------------------------------- Subject: 110) What is the error "Unaligned access in XmString" under Ultrix? Answer: Compile XmString.c with STRINGS_ALIGNED. ----------------------------------------------------------------------------- Subject: 111) TOPIC: KEYSYMS ----------------------------------------------------------------------------- Subject: 112) What is causing the messages "unknown keysym osfDown..."? It happens when I run an application under Motif 1.1 Answer: There is an OSF supplied addition to the /usr/lib/X11/XKeysymDB file. It is found on the release tape and should have been automatically installed if the installation procedure was followed in the Release Notes. You have to copy (or append) lib/Xm/XKeysymDB into /usr/lib/X11. This may require root permission. It is not clear how to fix the problem if you can't do this. The error comes from Xt translation table parsing and can't be fixed in Motif, so if you can't get root permission you may be stuck. The file is not copyrighted so you can install it on other systems. If X has been built so that XKeysymDB is not in this directory, and you don't know where it is looking, run 'strings libX11.a | grep XKeysymDB' to find the path. On a Sun running openwin with shared libraries, you may need to put the path for the library containing XKeysymDB *first* in the path list in LD_LIBRARY_PATH, or it may find the wrong XKeysymDB in the wrong directory. XKeysymDB simply contains the registered keysym values for the OSF keysyms. The OSF values are server-independent. And, all registered keysyms will be included in an XKeysymDB file to be shipped with X11R5. In the meantime (till all systems are X11R5+), a list of the registered keysyms can be found in the X11R4 release in mit/doc/Registry/Xregistry. ----------------------------------------------------------------------------- Subject: 113) What happens if I can't install Motif Keysyms? From: tessi!george@nosun.West.Sun.COM (George Mitchell) Here's what appears to happen if you don't have XKeysymDB in place to define OSF's virtual keysyms: 1. At class initialize time, for a widget (such as XmText) that uses virtual keysyms in its event translation table, all entries which refer to those keysyms fail to parse correctly. In the case of XmText, instead of ending up with a translation table with roughly 90 entries, you end up with one that has 29. 2. XKeysymDB doesn't exist, so you'd assume that KeyPress events will get translated to plain vanilla keysyms, right? WRONG! All Motif widgets install a virtual keysym translator ANYWAY! Consequently, the backspace key (for example) gets translated to the keysym osfBackSpace. 3. Therefore, if you augment or override your widget's translations with translations that refer to plain vanilla BackSpace, they will never be triggered, because you will NEVER see plain vanilla BackSpace, only osfBackSpace. 4. But you can't use osfBackSpace in an event translation entry, because you don't have XKeysymDB installed! Here's how I'm "dealing" with the problem right now: Motif installs its virtual keysym translator by calling XtSetKeyTranslator every time a VendorShell (or subclass) widget is created. So every time I create a shell, I immediately call XtSetKeyTranslator (display, XtTranslateKey) to restore the default translator. No more funny virtual keysyms! Now I can reinstall non- osfKeySym translations and have them work the way I expect. ----------------------------------------------------------------------------- Subject: 114) Why has OSF introduced Keysyms into Motif 1.1? They weren't there in Motif 1.0. Answer: From: ellis@osf.org Virtual Keysyms are meant to provide a consistent keyboard model for Motif applications running in a heterogeneous environment in which proprietary (i.e. vendor specific) non-Motif applications may also be running. First of all, for the sake of the rest of the readers, let's explain why this is an issue: It would be lovely if Motif's translation tables could just use the obvious keysyms predefined by X. For example, there are keysyms for XK_BackSpace, XK_Delete, XK_Left, XK_Right, etc. Shouldn't these be the ones that are used in our translations? Unfortunately, the problem is not so simple. Some specific examples: While most vendors bind XK_BackSpace to the key at the top right of the standard keyboard (often engraved with a leftwards pointing arrow), not all do. In fact, some vendors (including DEC) bind that key to XK_Delete. While most vendors bind the arrow keys to XK_Up, etc, a number of vendors (including Sun, on some servers) bind them to function key keysyms. A simplistic solution would require the use of xmodmap to change the offending bindings. That would work swell in an all Motif environment. However, OSF's goal (not always perfectly achieved) is interoperability. That is, we'd like to make sure that both Motif and non-Motif programs can happily run in the same environment. It is expected that a vendor may have a wide variety of existing X-based software that uses the keysyms as established by that vendor for specific purposes. It is expected that these applications may run at the same time as Motif-based software. Using xmodmap to change keysyms on the server side could "break" the existing applications (or at the very least their documentation) by making some keys unavailable, or by moving the location. So, we chose not to use xmodmap. By the way, though OpenLook uses a different implementation (they recompile their virtual translation tables into actual translation tables), they basically adopted the same approach, presumably for similar reasons. To work properly, the virtual keysym model we implemented depends on Xlib finding XKeysymDB installed appropriately (which standard Motif installation does). This simply defines the keysyms (not the key they are bound to). This unfortunate piece of stupidity is necessary because MIT only includes standard keysyms in keysymdef.h. It should be said that our lives would be made easier if MIT would also see fit to include registered keysyms in keysymdef.h as well. Motif applications determine how to bind virtual to actual keys by looking for either a resource or a property on the root window which describes what to do. Note that this information is on the server side, so that all applications use the same virtual bindings regardless of where they are running. Mwm will happily create the property if it finds a .motifbind file in your home directory when it starts up. (Actually, things generally work even if none of this is done, since if all else fails, the Motif toolkit chooses a virtual bindings table to use based on the identification of the server). The actual implementation of virtual keys is made possible by a hook in the Intrinsics. Undoubtably, the implementation would be simpler and cleaner if virtual key support was more directly supported by the Intrinsics. We will be exploring this possibility in the future. -- Ellis ----------------------------------------------------------------------------- Subject: 115) TOPIC: ICONS Iconification/de-iconification is a co-operative process between a client and a window manager. The relevant standards are set by ICCCM. Mwm is ICCCM compliant. The toplevel (non-override-redirect) windows of an application may be in three states: WithdrawnState (neither the window nor icon visible), NormalState (the window visible) or IconicState (the icon window or pixmap visible). This information is contained in the WM_STATE property but ordinary clients are not supposed to look at that (its values have not yet been standardised). Movement between the three states is standardised by ICCCM. ----------------------------------------------------------------------------- Subject: 116) How can I keep track of changes to iconic/normal window state? Answer: You can look at the WM_STATE property, but this breaks ICCCM guidelines. ICCCM compliant window managers will map windows in changing them to normal state and unmap them in changing them to iconic state. Look for StructureNotify events and check the event type: XtAddEventHandler (toplevel_widget, StructureNotifyMask, False, StateWatcher, (Opaque) NULL); .... void StateWatcher (w, unused, event) Widget w; caddr_t unused; XEvent *event; { if (event->type == MapNotify) printf ("normal\n"); else if (event->type == UnmapNotify) printf ("iconified\n"); else printf ("other event\n"); } If you insist on looking at WM_STATE, here is some code (from Ken Sall) to do it: /* ------------------------------------------------------------------ Try a function such as CheckWinMgrState below which returns one of IconicState | NormalState | WithdrawnState | NULL : ------------------------------------------------------------------ */ #define WM_STATE_ELEMENTS 1 unsigned long *CheckWinMgrState (dpy, window) Display *dpy; Window window; { unsigned long *property = NULL; unsigned long nitems; unsigned long leftover; Atom xa_WM_STATE, actual_type; int actual_format; int status; xa_WM_STATE = XInternAtom (dpy, "WM_STATE", False); status = XGetWindowProperty (dpy, window, xa_WM_STATE, 0L, WM_STATE_ELEMENTS, False, xa_WM_STATE, &actual_type, &actual_format, &nitems, &leftover, (unsigned char **)&property); if ( ! ((status == Success) && (actual_type == xa_WM_STATE) && (nitems == WM_STATE_ELEMENTS))) { if (property) { XFree ((char *)property); property = NULL; } } return (property); } /* end CheckWinMgrState */ ----------------------------------------------------------------------------- Subject: 117) How can I check if my application has come up iconic? I want to delay initialisation code and other processing. Answer: Use XtGetValues and check for the XmNinitialState value of the toplevel shell just before XtMainLoop. -- IconicState is iconic, NormalState is not iconic. ----------------------------------------------------------------------------- Subject: 118) How can I start my application in iconic state? Answer: From the command line application -iconic Using the resource mechanism, set the resource XmNinitialState to IconicState of the toplevel shell widget (the one returned from XtInitialise). ----------------------------------------------------------------------------- Subject: 119) How can an application iconify itself? Answer: In R4 and later, use the call XIconifyWindow. For R3, send an event to the root window with a type of WM_CHANGE_STATE and data IconicState. void IconifyMe (dpy, win) Display *dpy; Window win; /* toplevel window to iconify */ { Atom xa_WM_CHANGE_STATE; XClientMessageEvent ev; xa_WM_CHANGE_STATE = XInternAtom (dpy, "WM_CHANGE_STATE", False); ev.type = ClientMessage; ev.display = dpy; ev.message_type = xa_WM_CHANGE_STATE; ev.format = 32; ev.data.l[0] = IconicState; ev.window = win; XSendEvent (dpy, RootWindow (dpy, DefaultScreen(dpy)), True, (SubstructureRedirectMask | SubstructureNotifyMask), &ev); XFlush (dpy); } ----------------------------------------------------------------------------- Subject: 120) How can an application de-iconify itself? Answer: XMapWindow (XtDisplay (toplevel_widget), XtWindow (toplevel_widget)). ----------------------------------------------------------------------------- END OF PART FOUR -- +----------------------+---+ Jan Newmarch, Information Science and Engineering, University of Canberra, PO Box 1, Belconnen, Act 2616 Australia. Tel: (Aust) 6-2012422. Fax: (Aust) 6-2015041 Xref: bloom-picayune.mit.edu comp.windows.x.motif:13661 news.answers:4512 Newsgroups: comp.windows.x.motif,news.answers Path: bloom-picayune.mit.edu!enterpoop.mit.edu!news.media.mit.edu!micro-heart-of-gold.mit.edu!wupost!uunet!munnari.oz.au!manuel.anu.edu.au!csc.canberra.edu.au!news From: jan@ise.canberra.edu.au (Jan Newmarch) Subject: Motif FAQ (Part 5 of 5) Message-ID: <1992Dec10.001649.10616@csc.canberra.edu.au> Followup-To: comp.windows.x.motif Keywords: FAQ question answer Sender: news@csc.canberra.edu.au Reply-To: jan@ise.canberra.edu.au (Jan Newmarch) Organization: University of Canberra Date: Thu, 10 Dec 92 00:16:49 GMT Approved: news-answers-request@MIT.Edu Expires: +1 months Lines: 1847 Archive-name: motif-faq/part5 Last-modified: Thu December 12 1992 Version: 2.12 ----------------------------------------------------------------------------- Subject: 121) TOPIC: MISCELLANEOUS ----------------------------------------------------------------------------- Subject: 122)+ What is the matter with Frame in Motif 1.2? [Last modified: November 92] Answer: This announcement has been made by OSF: "IMPORTANT NOTICE We have discovered two problems in the new 1.2 child alignment resources in XmFrame. Because some vendors may have committed, or are soon to commit to field releases of Motif 1.2 and 1.2.1, OSF's options for fixing them are limited. We are trying to deal with these in a way that does not cause hardship for application developers who will develop applications against various point versions of Motif. OSF's future actions for correction are summarized. WHAT YOU SHOULD DO AND KNOW 1. Mark the following change in your documentation. On page 1-512 of the OSF/Motif Programmer's Reference, change the descriptions under XmNchildVerticalAlignment as follows (what follows is the CORRECT wording to match the current implementation): XmALIGNMENT_WIDGET_TOP Causes the BOTTOM edge of the title area to align vertically with the top shadow of the Frame. XmALIGNMENT_WIDGET_BOTTOM Causes the TOP edge of the title area to align vertically with the top shadow of the Frame. 2. Note the following limitation on resource converters for Motif 1.2 and 1.2.1 implementations. The rep types for XmFrame's XmNentryVerticalAlignment resource were incorrected implemented, which means that converters will not work properly. The following resource settings will not work from a resource file in 1.2 and 1.2.1: *childVerticalAlignment: alignment_baseline_bottom *childVerticalAlignment: alignment_baseline_top *childVerticalAlignment: alignment_widget_bottom *childVerticalAlignment: alignment_widget_top If you wish to set these values for these resources (note they are new constraint resources in XmFrame) you will have to set them directly in C or via uil. WHAT WE WILL DO The problem described in note #1 above will not be fixed in the OSF/Motif implementation until the next MAJOR release of Motif. At that time we will correct the documentation and modify the code to match those new descriptions, but we will preserve the existing enumerated values and their behavior for backward compatibility for that release. The fix for the problem described in note #2 will be shipped by OSF in Motif 1.2.2. SUMMARY We are sorry for any difficulty this causes Motif users. If you have any questions or flames (I suppose I deserve it) please send them directly to me. We sincerely hope this proactive response is better for our customers than you having to figure it out yourselves! Libby ----------------------------------------------------------------------------- Subject: 123) What is IMUG and how do I join it? Answer: IMUG is the International Motif User Group founded by Quest Windows Corporation and co-sponsored by FedUNIX. IMUG is a non-profit organization working to keep users informed on technical and standards issues, to strengthen user groups on a local level, to increase communication among users internationally, and to promote the use of an international conference as a forum for sharing and learning more about Motif. You can join it by 1. Pay the annual membership fee of $20 USD directly to IMUG. Contact IMUG 5200 Great America Parkway Santa Clara, CA 95054 (408) 496-1900 imug@quest.com 2. Register at the International Motif User Conference, and automatically become an IMUG member. 3. Donate a pd widget, widget tool or widget builder to the IMUG Widget Depository and receive a free one year IMUG membership. ----------------------------------------------------------------------------- Subject: 124) How do I set the title of a top level window? [Last modified: September 92] Answer: Set XmNtitle (and optionally XmNtitleEncoding) for TopLevelShells. (Note that this is of type String rather than XmStrin.) Ypu can also set XmNiconName if you want its icon to show this title. For XmDialogShells, set the XmNdialogTitle of its immediate child, assuming it's a BulletinBoard subclass. These can also be set in resource files. ----------------------------------------------------------------------------- Subject: 125) Can I use editres with Motif? [Last modified: August 92] Answer: It isn't built in to Motif (at 1.2.0), but you can do this in your application extern void _XEditResCheckMessages(); ... XtAddEventHandler(shell_widget, (EventMask)0, True, _XEditResCheckMessages, NULL); once for each shell widget that you want to react to the "click to select client" protocol. Then link your client with the R5 libXmu. David Brooks, OSF ----------------------------------------------------------------------------- Subject: 126) How can I put decorations on transient windows using olwm? Answer: From Jean-Philippe Martin-Flatin <syj@ecmwf.co.uk> /********************************************************************** ** WindowDecorations.c ** ** Manages window decorations under the OpenLook window manager (OLWM). ** ** Adapted from a C++ program posted to comp.windows.x.motif by: ** ** +--------------------------------------------------------------+ ** | Ron Edmark User Interface Group | ** | Tel: (408) 980-1500 x282 Integrated Systems, Inc. | ** | Internet: edmark@isi.com 3260 Jay St. | ** | Voice mail: (408) 980-1590 x282 Santa Clara, CA 95054 | ** +--------------------------------------------------------------+ ***********************************************************************/ #include <X11/X.h> #include <X11/Xlib.h> #include <X11/Xatom.h> #include <X11/Intrinsic.h> #include <X11/StringDefs.h> #include <X11/Protocols.h> #include <Xm/Xm.h> #include <Xm/AtomMgr.h> /* ** Decorations for OpenLook: ** The caller can OR different mask options to change the frame decoration. */ #define OLWM_Header (long)(1<<0) #define OLWM_Resize (long)(1<<1) #define OLWM_Close (long)(1<<2) /* ** Prototypes */ static void InstallOLWMAtoms (Widget w); static void AddOLWMDialogFrame(Widget widget, long decorationMask); /* ** Global variables */ static Atom AtomWinAttr; static Atom AtomWTOther; static Atom AtomDecor; static Atom AtomResize; static Atom AtomHeader; static Atom AtomClose; static int not_installed_yet = TRUE; static void InstallOLWMAtoms(Widget w) { AtomWinAttr = XInternAtom(XtDisplay(w), "_OL_WIN_ATTR" , FALSE); AtomWTOther = XInternAtom(XtDisplay(w), "_OL_WT_OTHER", FALSE); AtomDecor = XInternAtom(XtDisplay(w), "_OL_DECOR_ADD", FALSE); AtomResize = XInternAtom(XtDisplay(w), "_OL_DECOR_RESIZE", FALSE); AtomHeader = XInternAtom(XtDisplay(w), "_OL_DECOR_HEADER", FALSE); AtomClose = XInternAtom(XtDisplay(w), "_OL_DECOR_CLOSE", FALSE); not_installed_yet = FALSE; } static void AddOLWMDialogFrame(Widget widget, long decorationMask) { Atom winAttrs[2]; Atom winDecor[3]; Widget shell = widget; Window win; int numberOfDecorations = 0; /* ** Make sure atoms for OpenLook are installed only once */ if (not_installed_yet) InstallOLWMAtoms(widget); while (!XtIsShell(shell)) shell = XtParent(shell); win = XtWindow(shell); /* ** Tell Open Look that our window is not one of the standard OLWM window ** types. See OLIT Widget Set Programmer's Guide pp.70-73. */ winAttrs[0] = AtomWTOther; XChangeProperty(XtDisplay(shell), win, AtomWinAttr, XA_ATOM, 32, PropModeReplace, (unsigned char*)winAttrs, 1); /* ** Tell Open Look to add some decorations to our window */ numberOfDecorations = 0; if (decorationMask & OLWM_Header) winDecor[numberOfDecorations++] = AtomHeader; if (decorationMask & OLWM_Resize) winDecor[numberOfDecorations++] = AtomResize; if (decorationMask & OLWM_Close) { winDecor[numberOfDecorations++] = AtomClose; /* ** If the close button is specified, the header must be ** specified. If the header bit is not set, set it. */ if (!(decorationMask & OLWM_Header)) winDecor[numberOfDecorations++] = AtomHeader; } XChangeProperty(XtDisplay(shell), win, AtomDecor, XA_ATOM, 32, PropModeReplace, (unsigned char*)winDecor, numberOfDecorations); } /* ** Example of use of AddOLWMDialogFrame, with a bit of extra stuff */ void register_dialog_to_WM(Widget shell, XtCallbackProc Cbk_func) { Atom atom; /* ** Alias the "Close" item in system menu attached to dialog shell ** to the activate callback of "Exit" in the menubar */ if (Cbk_func) { atom = XmInternAtom(XtDisplay(shell),"WM_DELETE_WINDOW",TRUE); XmAddWMProtocolCallback(shell,atom, Cbk_func,NULL); } /* ** If Motif is the window manager, skip OpenLook specific stuff */ if (XmIsMotifWMRunning(shell)) return; /* ** Register dialog shell to OpenLook. ** ** WARNING: on some systems, adding the "Close" button allows the title ** to be properly centered in the title bar. On others, activating ** "Close" crashes OpenLook. The reason is not clear yet, but it seems ** the first case occurs with OpenWindows 2 while the second occurs with ** Openwindows 3. Thus, comment out one of the two following lines as ** suitable for your site, and send e-mail to syj@ecmwf.co.uk if you ** find out what is going on ! */ AddOLWMDialogFrame(shell,(OLWM_Header | OLWM_Resize)); /* AddOLWMDialogFrame(shell,(OLWM_Header | OLWM_Resize | OLWM_Close)); */ } ----------------------------------------------------------------------------- Subject: 127) Why does an augment translation appear to act as replace for some widgets? When I use either augment or override translations in .Xdefaults it seems to act as replace in both Motif 1.0 and 1.1 Answer: By default, the translation table is NULL. If there is nothing specified (either in resource file, or in args), the widget's Initialize finds: Oh, there is NULL in translations, lets use our default ones. If, however, the translations have become non-NULL, the default translations are NOT used at all. Thus, using #augment, #override or a new table has identical effect: defines the new translations. The only way you can augment/override Motif's default translations is AFTER Initialize, using XtSetValues. Note, however, that Motif managers do play with translation tables as well ... so that results are not always easy to predict. From OSF: A number of people have complained about not being able to augment/override translations from the .Xdefaults. This is due to the complexity of the menu system/keyboard traversal and the necessary translations changes required to support the Motif Style Guide in menus. It cannot be fixed in a simple way. Fixing it requires re-design of the menus/buttons and it is planned to be fixed in 1.2. ----------------------------------------------------------------------------- Subject: 128) How do you "grey" out a widget so that it cannot be activated? Answer: Use XtSetSensitive(widget, False). Do not set the XmNsensitive resource directly yourself (by XtSetValues) since the widget may need to talk to parents first. ----------------------------------------------------------------------------- Subject: 129) Why doesn't the Help callback work on some widgets?